【レポート】AWS のコンテナ入門 #AWSSummit
はじめに
オペレーションチームの下田です。
2018年 5月 30日(水) 〜 6月 1日(金)の期間に、グランドプリンスホテル新高輪で開催される日本最大級のクラウドコンピューティングカンファレンス AWS Summit Tokyo 2018 に参加しています。
「AWS のコンテナ入門」を聴講しましたので、レポートしたいと思います。 スピーカーは、アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 兼松 大貴さんです。
セッションに関する紹介文を、公式サイトから引用します。
マイクロサービスや CI/CD の実現、またリソースの効率性や再利用性などの獲得を目的に検討されることが多いコンテナ技術ですが、実際に利用する際には可用性や拡張性、セキュリティ など管理面でいくつかの検討すべき課題があります。本セッションでは、コンテナが注目されている背景および基本的な技術概要から始まり、これらの課題に対 して AWS のコンテナ管理サービスでどう解決することができるのか、事例を交えてご紹介します。
レポート
- 対象者
- コンテナを使ったことがなかったり、使ったことはあるがあまり知らない
- 狙い
- なぜコンテナなのか?を背景から理解してもらう
- コンテナの技術的な概要や価値を知ってもらう
- 話さないこと
- コンテナの技術的な詳細
- コンテナが注目される背景
- 新しい技術ではない(Unix chroot, Solaris Zone, OpenVZ Paralleles, Linux Cgroups,AIX Wpar, Linux LXC, Docker)
- ビジネス環境の変化、アプリ開発の変化、クラウドの普及(軽量、分離性、可搬性が高い)
- コンテナとは?
- 一言で言えば「リソース隔離されたプロセス」
- コンテナの特徴とメリット
- リソース効率が高い
- スピード(起動が高速)
- 柔軟性
- 可搬性
- Docker の登場
- OSS
- Linux/Windows で稼働する
- 豊富な機能を提供
- キーとなるコンポーネント
- Docker コンテナ(アプリの実行環境、イメージから起動する)
- Docker イメージ(OS やアプリを含むコンテナのテンプレート、レジストリに格納する)
- Docker レジストリ(イメージを格納するレジストリ、パブリック、プライベートで構築できる)
- Dockerfile(OS のイメージおよびアプリケーションの動作や環境に関してソースコードで表現することのできるファイル)
- Docker クライアント(Docker 環境にアクセスするクライアント)
ライブデモ(Apache の環境を Docker コンテナで起動してみよう)
以下のような作業を、デモンストレーションされておりました。
EC2 に対して、Docker を予めインストールしておくために以下の作業が必要な旨の説明をされておりました。
$ sudo yum install -y docker $ sudo service docker start
以下は、デモで利用されていた Dockerfile です。 ローカルの html 配下に index.html ファイルが存在している前提であることを説明されておりました。
FROM httpd:2.4 COPY ./html/ /usr/local/apache2/htdocs/
下記のコマンドを実行し、Docker ファイルからビルドされたコンテナイメージを利用してコンテナを起動しておりました。
$ docker build . -t aws-image $ docker images $ docker run --name aws-container -p 8080:80 -dit aws-image
- またコンテナが起動していることを確認するために、ブラウザから 8080 ポートにアクセスして HTML を確認されておりました。
最後に、下記のコマンドラインを実行してコンテナ内の bash にアクセスできる旨を説明されておりました。
docker exec -it aws-container bash
ユースケースとコンテナ活用の概要
- コンテナの主なユースケース
- 非同期ジョブ実行(バッチ)
- マイクロサービスアーキテクチャ
- 継続的インテグレーション、継続的デプロイ(CI/CD)
- クラウドへのマイグレーション
- コンテナ活用のポイント
- アプリ開発に Transformation が必要(12 Factor Apps、1 タスク = 1 コンテナ)
- 運用を考慮した仕組みが必要(コンテナをどのように管理するか?、ログやセキュリティ、オーケストレーションなど)
- アンチパターン(タスクやログ、設定やデータがごちゃまぜ)
- ベストプラクティス(シンプルに)
- 運用を考慮した仕組みが必要
- コンテナを動かすだけなら簡単だが、複数のホスト上で管理するのは困難
- なぜ困難なのか?(各ホストのリソース消費量をリアルタイムで把握、監視するのが大変)
- 非常に複雑だが、ここを頑張ってもビジネスの差別化につながらないし、つながりにくい
- AWS コンテナ関連サービス
- Amazon ECS(コントローラープレーン、コンテナ管理サービス)
- AWS 上の本番環境のコンテナを支える
- VPC ネットワークモードや、他の AWS サービスとの深い連携
- SLA: 99.99%
- Amazon EKS(コントローラープレーン、コンテナ管理サービス)
- #EKS については、スライドによる紹介はありませんでした。
- Amazon ECR(コンテナレジストリ)
- フルマネージドの高可用性、スケーラブルなレジストリ
- AWS IAM による強力な認証管理機構
- ライフサイクルポリシーでイメージの自動クリーンアップ
- AWS Fargate(データプレーン)
- アプリケーションの開発に集中したい
- インスタンスの管理はしたくないというフィードバックに基づき開発された
- 計算リソースの使い方を根本的に変える(簡素で、使いやすく、強力な新しいリソースモデル)
- SLA: 99.99%
- Amazon ECS(コントローラープレーン、コンテナ管理サービス)
まとめ
- コンテナは昔からあるリソースを隔離する技術(軽量でリソース効率がよく、可搬性も高い)
- ただし、アプリケーション開発の transformation も必要(本番運用するためには様々な仕組みと考慮が必要)
- AWS では様々なコンテナ管理サービスを提供している(そのため、アプリケーションの開発に専念することが可能。また、S3 や RDS など他のサービスとの連携も可能)
アプリケーション側をコンテナに合わせた実装に変更する(セッションでは、transformation と説明されていた)必要はありますが、CI/CD 含め本番環境で運用するまでの仕組みや環境が整えば開発者にとってのメリットは凄く多いサービスだと個人的に感じているため、コンテナについて興味がなかった、使ったことがなかったという方がおられましたら(今からでも遅くはありません!)、一度使われてみてはいかがでしょうか。
現場からは以上です、ではでは